I/O scheduler is used by computer operating systems to decide in which order block I/O operations will be submitted to storage volumes. Depending on different goals to achieve, one I/O scheduler may minimize time wasted by hard disk seeks, prioritize a certain processes of I/O requests, give a share of the disk bandwidth to each running process, and/or guarantee certain I/O requests being issued before a particular deadline. For example, Deadline scheduler in Linux kernel is used to guarantee a start service time for a request. It does so by imposing a deadline on all I/O operations to prevent starvation of requests. Hence, the deadline scheduler favors reads over writes via use of separate I/O queues. It runs well for database workloads. Another example is Complete Fair Queuing (CFQ) scheduler. The CFQ scheduler places synchronous requests submitted by processes into a number of per-process queues and then allocates time slices for each of the queues to access the disk. Thus, the CFQ scheduler is suitable for sequential read video or audio streaming and workloads from general hosts.
The schedulers mentioned were proposed to improve performance of a HDD or of a storage system composed of HDDs. There are certain characteristics of HDDs described below. First, multiple I/O requests (both read and write) may be merged to form a single request which is processed in one movement of a read-and-write head (r/w head). Therefore, the number of movements of the r/w head can be reduced and that increases HDD's throughput. Second, I/O requests are sorted to improve seek time by reducing forward-and-backward movement of HDD's r/w head. Based on the characteristics, I/O requests waiting in queue for future processing may be merged and sorted. Workloads with different characteristics can be processed with better performance when using different schedulers.
A main stream of storage systems, especially for those of a cloud system, is to use a combination of Solid State Drives (SSDs) and HDDs. Besides HDDs, there are SSDs in the storage systems, thus most current schedulers may not meet their goals when they are applied thereto. Different from HDDs, SSDs have distinct characteristics illustrated below. First, the SSDs don't need to merge and sort SSD I/O requests, which imply no merging and sorting time needed. The I/O requests should be sent to SSD as soon as possible. Second, SSD I/O requests might be parallelized because many modern SSDs have multi-channels, which can accommodate multiple I/O requests at the same time. If the storage system applying the scheduler is a software-defined hybrid storage system, the situation is more complex for the scheduler to handle. Hence, current schedulers should be modified to take the existence of SSDs into consideration.
In addition, traffic characteristics of a workload are another important issue for further investigation. Any workload may have some properties that are different from others. The properties may be an I/O pattern (sequential or random), a read/write ratio, a SSD cache hit ratio, etc. For example, a workload of an On-Line Transaction Processing (OLTP) database has a random I/O pattern, a read/write ratio greater than 1, and smaller storage block size; while another workload of a MongoDB has a sequential I/O pattern, a read/write ratio smaller than 1, and larger storage block size. If the two workloads run over the same hybrid storage system, the current scheduler nowadays cannot meet the performance requirement in the Service Level Agreements (SLA) for both. At least, a noisy neighbor problem exists to affect the workloads.
There are some prior arts regarding solutions for the above requirement. One example is disclosed in the U.S. Pat. No. 8,756,369. In '369, a storage system includes a command sorter to determine a target storage device for at least one of a SSD command and a HDD command, place the command in a SSD ready queue if the SSD command is targeted to a SSD storage device of the storage system, and place the HDD command to a HDD ready queue if the HDD command is targeted to an HDD storage device of the storage system. The storage system also includes a SSD ready queue to queue the SSD command targeted to the SSD storage device, and a HDD ready queue to queue the HDD command targeted to the HDD storage device. Meanwhile, a command scheduler takes the HDD and SSD commands from the ready queues and places the commands into a command processor. The command scheduler places a particular (HDD or SSD) command from its respective ready queue into the command processor based on an availability level of a process queue corresponding to a target device of the particular command. Then, the command processor gives the storage commands to the process queues.
The storage system provided by the '369 differentiates HDD commands (I/O requests) from SSD commands. It helps for hardware operation for one workload. However, if multi-workloads are applied, the storage system may not work as it is set to be. On the other hand, for a variety of workloads run over the storage system, there is no suitable way to coordinate the requests from every workload so that each workload can meet the requirement in the SLA or a Quality of Service (QoS) requirement. Therefore, a workload-aware I/O scheduler in a software-defined hybrid storage system to settle the problems mentioned above is desired.